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PATENT 



SYSTEM AND METHOD TO VERIFY 
AVAILABILITY OF A BACK-UP SECURE TUNNEL 

Cross Reference to Related Applications 

This patent application is related to, and contains common disclosure with^ co-pending and 
commonly assigned patent application "Apparatus, Method and System for Secure Tunnel Ping and 
Message Format for Use Therein", serial number 09/438,1 19, filed November 10, 1999; "System 
and Method to Monitor if an Active IPSec Tunnel has Become Disabled", serial number (attorney 
docket number RAL9-1999-0037 USl); "System and Method to Determine Connectivity of a VPN 
Secure Tunnel", serial number (attorney docket number RAL9- 1999-003 8 USl); and " System and 
Method for Conversion of an ICMP Ping to an IPSec Ping via a Proxy-Ping Function", serial number 
(attorney docket number RAL9-1 999-003 5US1). The co-pending patent appKcations are hereby 
incorporated by reference into this description as fully as if here represented in full. 

Background Of The Invention 

The present invention relates to improvements in the systems and methods for 
communicating in an environment including at least one secure tunnel (such as is sometimes referred 
to as Internet Protocol Security or "IPSec" herein and in the industry and its standards activity). 
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Communications systems involve a variety of devices which are connected to a data 
transmission network, often through a variety of conventional devices such as routers, switches and 
other components. As the networks have become larger, incorporating local area networks (LANs) 
and wide-area networks (WANs), these networks have become more complex and involve an 
5 increasing number of components. One of the largest networks is referred to as the Internet, a 
constantly-changing communications network including a large number of interconnected network 
devices or workstations. 

In addition, many companies are now applying Internet technologies to build private 
p Intranets, enabling users in an organization to go beyond electronic mail and access critical data 
K) through web browsers. While Internet traffic is currently composed primarily of text, graphics, and 
H images, this traffic is expected to expand in the near term to include more bandwidth intensive audio, 
2 video, voice, and multi-media applications. 

p As applications proliferate and demand ever greater shares of bandwidth at the desktop and 

O as a total number of users continues to grow, the pressure for increased bandwidth will continue to 
25 grow at the desktop, the server, the hub, and the switch. Organizations will need to migrate critical 

portions of their networks to higher bandwidth technologies, such as Gigabit Ethernet, Fast Ethernet, 

Gigabit Token-Ring, and High Speed Token-Ring. 

Successfiil communications requires that each message be properly addressed within the 

communications system and that each link in the communications system be connected to the system 
20 and perform properly. If any of the links fail, communications through the failed link will not be 

successful. When communications through the system have failed, it is necessary to isolate the 
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problem so it can be resolved, a process which involves testing the components, either individually 
or in groups. 

One method of testing a communications system to determine if it is properly connected and 
performing is called a "ping". A ping is a message sent from a first network device and addressed 
to a second network device with the request that a responsive message be returned from the second 
network device to the first device, indicating that both network devices and the intervening network 
devices are properly connected to the network and that each is working appropriately. 

A ping is also used in testing large and complex networks. It is particularly usefiil for testing 
the network in portions. Thus, when the entire network is not properly working pings may be used 
to isolate the problem. In essence, a portion of the network can be tested and determined to be 
operating properly, indicating that any problem in the larger network must be located elsewhere. 

Communications on the Internet presents additional problems because of the size of the 
network and because communications are not handled in a uniform manner ~ a first packet between 
two devices may be sent over one route and a completely different path may be used for a second 
packet, even when both packets are part of the same message. Furthermore, the Internet is inherently 
unsecure. As security techniques are defined to add security to the Internet, these techniques often 
conflict with the techniques (such as the "ping" testing methods) which have been in common use. 

As organizations such as the Internet Engineering Task Force (IETF) define techniques for 
reducing the, security exposures of Internet communications, security concepts such as IP security 
(IPSec) have been proposed. IPSec is a developing standard for security at the network or packet 
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processing layer of network communications. Earlier security approaches inserted security at the 
apphcation layer of the communications model. IPSec is especially useftil for implementing virtual 
private networks (VPNs) and for remote user access through dial-up connection to private networks. 
A big advmitage of IPSec is that security arrangements can be handled without requiring changes 
to individual user computers. IPSec provides two choices of security service: Authentication Header 
(AH), which allows authentication of a sender of data and Encapsulating Security Payload (ESP) 
which supports both authentication of the sender and encryption of the data as well. The specific 
information associated with each of these services is inserted into the packet in a header that follows 
the IP packet header. Separate key protocols can be selected, such as the IS AKMP/Oakley protocol 

One feature of IPSec includes secure tunnels, in which a single logical tunnel is limited to 
communication of messages from a single source address to a single destination address and which 
may require other specific security features defined for communication between network devices. 
A secure tunnel in such commxmications systems inherently provides a limited, one-way 
communications path because its definition allows only messages from a single source to a single 
destination, so that a return message from the original destination back to the original source cannot 
use the same secure tunnel as the message going the other way, but such return message must use 
a different path such as a different secure tuimel with its own security requirements. 

Tunneling or encapsulation is a common technique in packet-switched networks. It consists 
of wrapping a packet in a new one. That is, a new header is attached to the original packet. The 
entire original packet becomes the payload of the new one. In general, tunneling is used to carry 
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traffic of one protocol over a network that does not support that protocol directly. For example, 
NetBIOS or IPX can be encapsulated in IP to carry it over a TCP/IP wide area network (WAN) link. 
In the case of IPSec, IP is tunneled through IP for a slightly different purpose, i.e., to provide total 
protection, including the header of the encapsulated packet. If the encapsulated packet is encrypted, 
an intruder cannot figure out the destination address of that packet. Without tunneling the intruder 
could. The internal structure of a private network can be concealed in this manner. 

A notable advantage of IP tunneling is the possibility to exchange packets with private IP 
addresses between two intranets over the pubhc Internet, which requires globally unique addresses. 
Since the encapsulated header is not processed by the Internet routers, only the end points of the 
tunnel (the gateways) need to have globally assigned addresses; the hosts and the intranets behind 
them can be assigned private addresses. As globally unique IP addresses are becoming a scarce 
resource, this interconnection method gains importance. 

IPSec can be configured to create tunnels in two modes: 

1 . Tunnel mode - in which the protocol data unit (PDU) is encapsulated within another IP 
frame and an outermost IP address is added. This address is the address of the tunnel termination 
device. 

2. Transport mode - in which the PDU is not encapsulated and the existing (outermost) IP 
address is used. This address is the address of the tunnel termination device. 
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The present invention applies to tunnel mode. Note that in IPSec terminology, the word 
tunnel is used to describe both a mode of operation, i.e., tunnel mode (a new header is created to 
encapsulate the original IP frame), or transport mode (no new header is created). 

It is necessary to have certain information in order to use a secure tunnel: for example, the 
configuration/policy for IPSec devices may require a "legal address", a security protocol indicator 
(also known as an SPI value) and a valid key before an originating device can send frames through 
a secure tunnel to a destination device. 

Prior art secure communications systems have disadvantages and limitations and constructing 
a message for providing a ping in a system of secure tunnels is far from a simple process and may 
depend on information which is hard to acquire and difficult to use. Furthermore, the entire concept 
of a "ping" message in a secure tunnel environment such as the IPSec proposed by a standards 
organization may be difficult to implement, in view of the construction and operation of the secure 
tunnels which have the effect of Hmiting communication and requiring strict adherence to certain 
communications protocols. 

The above-referenced co-pending, commonly assigned patent application "Apparatus, 
Method and System for Secure Tunnel Ping and Message Format for Use Therein" provides a "ping" 
method for testing a secure communication system. During the hfe of an IPSec tunnel, a variety of 
problems may occur to disrupt the connectivity of the tunnel. Within the IPSec standard, there is 
no "keep alive" or "heart beat" protocol to detect that a tunnel is no longer fimctioning, thus there 
is no method at the network layer that can detect this. 
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Summary of the Invention 

The present invention overcomes the disadvantages and Hmitations of the prior art 
communications systems, particularly in the secure tunnel environment. More particularly, the 
present invention provides a method and system for determinmg if an existing IPSec tunnel that is 
not actively used and that has been configured as a back-up tunnel between network elements in a 
secure communication system is still active and, if not, sending a notification to a network 
administrator. Such an invention has particular applicability in a secure tunnel system of the type 
described in proposed standards such as the IPSec protocol. 

The present invention has the advantageous effect that it facilitates testing of the secure 
tunnel capability of a network, in addition to testing the physical connections of the network. 

The present invention has the advantageous feature that it may be used without regard to the 
configuration of the destination device. In fact, the destination device may not even reaUze that a 
"ping" message has passed through it and returned to the device originating the message. 

The present invention has the benefit that knowledge of the outgoing message handUng 
procedures or protocols of the destination device is not required on the part of the originating 
machine. This is because the destination device passes the "ping" message back to the originating 
device through the destination device's normal handling of outgoing mail, such as an IP protocol 
stack. 
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The present invention has the advantage that the return message from a destination device 
passes through the secure tunnels, for example, of the type referred to as the IPSec tunnels proposed 
by the IETF. 

Other objects and advantages of the present invention will be apparent to those skilled in the 
relevant arts in view of the following detailed description of the preferred embodiment, taken in 
conjimction with the appended claims and the accompanying drawings. 

Brief Description of the Drawings 

The invention is better understood by reading the following detailed description of the 
invention in conjunction with the accompanying drawings, wherein: 

Figs. 1 A - IB illustrate ff Sec back-up tunnels between the same network elements as are 
used for the active tunnel and between different network elements than are used for the active tunnel. 

Fig. 2 illustrates an embodiment of a system configuration of the invention. 

Fig. 3 illustrates the processing logic to determine if an IPSec back-up tunnel is usable. 

Fig. 4 illustrates a simplified systems configuration for a secure communications 
environment of the present invention, having two one-way tunnels between two network devices. 

Fig. 5 illustrates a logical representation of the system of Fig. 3, with added detail on the 
content of messages sent between the two devices shown. 
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Fig. 6 illustrates a logical rq)resentation of a portion of the system of Fig. 4 showing an 
originating network device and the message content sent by the network device in practicing the 
present invention. 

Fig. 7 illustrates a logical representation of a portion of the system of Fig. 4, showing an 
originating network device with the returned message from a destination network device. 

Fig. 8 illustrates processing logic for handling a returned IPSec message. 

Fig. 9 illustrates a representation of the message sent from the originating network device 
to the destination network device to practice the present invention. 

Fig. 1 0 illustrates an alternate embodiment of the present invention for use in an Internet and 
firewall envkonment of an alternate network. 

Fig. 1 1 illustrates a logical view of selected fields from the Tunnel Definition data base. 

Detailed Description of the Invention 

The following detailed description of the present invention is provided as a detailed, enabling 
teaching of the present invention in its best currently-known embodiment. Those skilled in the 
relevant arts will recognize that many changes can be made to the embodiment described while still 
obtaining the beneficial results of the present invention. It will also be apparent that some of the 
desired benefits of the present invention can be obtained by selecting some of the features of the 
present invention without using other features. Accordingly, those who work in the art will reaUze 
that many modifications and adaptations to the present invention are possible and may even be 
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desirable in certain circumstances and are a part of the present invention. Thus, the following 
description is provided as illustrative of the principles of the present invention and not in limitation 
thereof, since the scope of the present patent is defined by the claims. 

IPSec (IP Security) is an extension to the Internet Protocol (IP) protocol stack which provides 
secure tunnels between the IP stacks in two network elements. The Internet Engineering Task Force 
(IETF) has a number of draft standards supporting IPSec; the overview architecture is found in 
Request for Comments (RFC) 2401, "Security Architecture for the Internet Protocol". 

This invention defines a method to determine if an existing IPSec Tunnel that is not actively 
used and has been configured as a back-up tunnel between the network elements has stopped 
working. Since the tunnel is logical, rather than physical, a method using IPSec itself must be used 
(i.e., the physical interface may be up and passing traffic, but the logical mnnel formed by IPSec can 
be down). 

IPSec, in tunnel mode, encapsulates an IP header, the inter PDU, within a new IP header and 
sends the fi-ame to the upper IP stack for decapsulation. Filter or access controls define what firames 
(by protocol type, IP address, etc.) are allowed to flow through the tunnel. These filter/access 
controls (called configurations or policies) are set as restiictive as possible in an attempt to prevent 
unauthorized traffic fi-om flowing through the tunnels. Currently, unless the IPSec filter/access 
controls at the originating endpoint are explicitly configured to allow the ping out of the tunnel, it 
is not desirable to allow the ping to flow through the tunnels. Thus, a new method to accompUsh 
the same purpose as a ping is needed. Such method is described in co-pending patent appUcation 
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"Apparatus, Method and System for Secure Tunnel Ping and Message Format for Use Therein". 
The present invention utilizes the IPSec Tunnel Ping although this is not essential to the present 
invention if an alternative methodology to test the PSec tunnel is available. 

The need for having an unused back-up tunnel may not be readily apparent. An owner of 
a private network may contract with two hitemet Service Providers (ISPs) for access to the Internet. 
All traffic may be tunneled over one ISP. If there is a failure in the logical tunnel in the main ISP, 
the administrator of the private network would move to the back-up ISP. The back-up ISP tunnel 
must be logically up to do this quickly. The cost of having a back-up tunnel operational, but not 
used, is small. As illustrated in Figs. 1 A - IB, a back-up tunnel can be through different paths 
(interfaces) between the same network equipment (Fig. 1 A) or it can be between different network 
equipment (Fig. IB). 

The present invention solves the problems of how to associate the back-up link with the 
primary link, and how to verify the connectivity of the back-up link itself. 
In a robust network configuration, back-up links are available if needed. For IPSec tunnels, these 
links are logical, i.e., the physical port that a link is on may be up, but the logical IPSec link can be 
unavailable. In some networks, the administrator will "bring up" the primary tunnel and a back-up 
tunnel simultaneously. No data traffic is sent through the back-up tunnel. During the life of the 
back-up IPSec tunnel, a variety of problems can occur to disrupt the connectivity of the tunnel. 
Within the IPSec standard, there is no association of a primary link with its back-up link; and no 
"keep alive" or "heart beat" protocol to detect that a tunnel is no longer functioning. Thus, there is 
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no method at the network layer that can detect that the back-up tunnel is no longer available if it is 
needed. 

The following description describes a system and method to associate a primary link with 
its back-up link and then to detect that an IPSec back-up tunnel's connectivity has been lost. This 
invention uses the EPSec tunnel ping described in the co-pending patent application "Apparatus, 
Method and System for Secure Tunnel Ping and Message Format for Use Therein" . In one preferred 
embodiment, the back-up tunnel verification method is initiated from either: 

1 . a command given at a console interface on the network element that forms the tunnel 
(A in Fig. 2); 

2. initial configuration of the network element that forms the tunnel (B in Fig. 2); or 

3. a network management entity, i.e., the network administrator (C in Fig. 2). 

The results of the method is returned to either the console interface and/or a network 
management entity, C in Fig. 2. C can be any network management system that accepts unsolicited 
notifications, i.e.. Simple Network Management Protocol (SNMP) traps. The results can also be 
stored locally, i.e., in a log file or in a Management Information Base (MIB). 

Note that in Fig. 2, for illustrative purposes, the IPSec "tunnel" between two network 
elements is composed of two unidirectional tunnels. The soUd lines originating at A, B and C 
indicate the flow which instantiates the function and the corresponding dashed lines indicate the 
results. 
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upon instantiation of the back-up tunnel verification function and using the IPSec Tunnel 
Ping (ITP), the function periodically verifies the connectivity of the back-up IPSec tunnel with the 
following algorithm (or a variant thereof). For purposes of illustration, the implementation abstract 
of the Back-up Tunnel Verification function (BTV) is given by the following parameters: 

BTV the command, e.g.. Back-up Tunnel Verification; 

id the identification of the primary tunnel; 

time_to__run the time that the back-up verification function will be active; 

time_between the time to wait between each verification attempt; 

number_of___failures the number of consecutive failures of connectivity attempts required 
to determine that the tunnel is no longer available; 

who_to_tell the entity to which the notification should be sent, e.g., the console, 

a receiver of SNMP traps, a MDB table, a log file, etc.; and 

bytes the payload size of the connectivity test packet. 

A similar command can be envisioned to stop the function before the time has expired, i.e., 
BTV STOP. However, in the preferred embodiment, the time_to_run is set to the tunnel validity 
period. In one implementation, the entity is the console and/or the IP address of the SNMP network 
management station to which an SNMP trap will be sent followed by the SNMP community name 
to send the SNMP trap. The SNMP trap will contain the tunnel ID and the tunnel Index (index into 
the IPSec Tunnel Table). In other implementations, the entity could be any entity which can receive 
an vinsolicited notification such as an e-mail address. 
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The above parameters, although not needed to instantiate the Back-up Tunnel Verification 
function, are provided for flexibility and future extensions. In the preferred embodiment, this 
function would automatically be instantiated when a "back-up" tunnel was configured, i.e., unless 
explicitly instantiated, the function parameters would default to the following: 

time_to_run: the vaUdity period of the back-up tunnel; 

time_between: 5 seconds; 

number_of_failures: 1; 

who_to_tell the console and/or all configured SNMP trap receivers, i.e., network 

management entities; and 
bytes: 0 (no extra bytes typically needed). 

Fig. 3 illustrates the processing logic of the Back-up Tunnel Verification function. 
Processing starts from either start block 300 or start block 302. Start processing logic block 300 
represents a start from a console or initial configuration. Start processing logic block 302 is started 
by a network management entity. From either start processing logic block, processing continues as 
indicated in logic block 304 by obtaining the back-up general policy name via a pointer to the back- 
up tunnel policy from the primary tunnel poUcy. In decision block 306, a test is made to determine 
if an IKE or a manual key tunnel is in use. If it is an IKE tunnel, then in decision block 308, a test 
is made to determine if phase II of the IKE process is up. In phase I, two ISAKMP peers estabUsh 
a secure, authenticated channel with which to commimicate. This is called the ISAKMP security 
association. In phase II, a "Quick Mode" is used to derive keying material and negotiate shared 
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policy for non-ISAKMP security associations. If IKE phase II is not up, then, in logic block 310 a 
request is made for the IKE (phase I) process to generate a phase II connection. Processing then 
loops back to decision block 308. If in decision block 306, a manual key tunnel is indicated, then 
processing continues in logic block 312 with obtaining the back-up tunnel identification. Likewise, 
in decision block 308, if an IKE phase II connection has been generated, processing continues in 
logic block 3 1 2 in which the back-up tunnel identification is obtained. Next, in decision block 314, 
a test is made to determine if the time_to_run has expired or if a stop has been received. If the 
answer is yes, then processing ends in termination block 318 with the results retumed to the caller 
(i.e., who_to_tell parameter). If the time_to_run has not expired and a stop has not been received, 
then in logic block 3 16, a wait period is entered based on the time_between parameter. The IT? of 
size "bytes" is then sent through the tunnel ID, as indicated in logic block 320. A test is made in 
decision block 322 to determine if the IT? has been retumed. If it has been, then the failure counter 
is reset, as indicated in logic block 324. If the IT? has not been retumed, then the failure counter 
is incremented as indicated in logic block 326. From either logic block 324 or logic block 326, 
processing continues in decision block 328 with a determination of whether or not the failure count 
exceeds the number_of_failures parameter. If it does, then processing ends in termination block 330, 
with results retumed to the caller (i.e., who_to_tell parameter) that the back-up tunnel is not 
operational. If the failure count does not exceed the number__of_failures parameter, processing loops 
back to decision block 314, where a test is again made to determine if the time_to_run has expired 
or a stop has been received. 
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The "Obtain Back-up Tunnel ID via Pointer to Back-up Tunnel Policy from Primary Tuimel 
Policy" block 304 requires the following extension to the current scheme or box-level configuration 
(either console or graphical user interface (GUI) configuration tool): adding a pointer field that 
contains the policy name of the back-up tunnel. This is a multi-valued field with the order of the 
variables indicating the priority of use of back-up tunnels. Note the above simphfied description of 
the processing logic uses only the first value (back-up tunnel poUcy name) in this field. 

The results are returned per the user's choice, e.g., retumed to the console, or an unsoUcited 
notification (SNMP trap) is sent to a network management application. The network management 
"results table" (i.e., SNMP MIB table) is updated, a log file is written to, etc. The prime result is an 
indication that the IPSec back-up tunnel is no longer available. 

This system and method provides an owner of a private network with the ability to 
continually assure working connectivity of an IPSec back-up tunnel prior to attempting to place 
traffic into it. Currently there is no mechanism to monitor the availability of a back-up IPSec tunnel 
and infomi the administrator when the turmel has become unavailable. 

Fig. 4 illustrates communication between a first network device 1 0 (device A) and a second 
network device 20 (device B) with a first secure tuimel 32 cotmecting the first network device 10 to 
the second network device 20 and a second seciure tunnel 34 connecting the first network device 10 
to the second network device 20. The first network device 1 0 and the second network device 20 may 
be secure devices of the type sometimes referred to as IPSec devices and a packet of information can 
flow through the secure tunnels connecting them in accordance with the protocols established for 
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the secure tunnels. Typically, a given tunnel, such as tunnel 32 will define a unidirectional path in 
the direction of the arrow 32A, that is, allowing packets to pass from the first device 1 0 to the second 
device 20 (but not in the other direction, from the second device 20 to the first device 10), by 
requiring that the source of the packet to be the address of the first device 10 and requiring the 
destination to be the address of the second device 20 in order to use the tunnel 32. A tunnel has a 
Security Association which defines a data structure that describes which transformations are to be 
applied to datagrams that use the tunnel and how the transformations are to be applied. An SA is 
a unidirectional logical connection between two IPSec systems. An arbitrary 32-bit number called 
the Security Parameter Index (SPI), the destination address and the IPSec Protocol Identifier are 
used to uniquely identify each S A. The SPI is assigned to an S A when the S A is negotiated, and is 
used to identify different SAs with the same destination address and security protocol.. 

Each packet or datagram must have the appropriate Security Parameter Index or SPI (shown 
here as SPI__1) and key(s) (shown here as Key_l) in order to use the first tunnel 32. The path for a 
packet from the second device 20 to the first device 10 is shown as a second tunnel 34, operating in 
the direction of the arrow 34B and using SPI_2 and Key_2. 

The first and second tunnels 32, 34 may be either physical or logical tunnels, and a plurality 
of tunnels may be associated with each EPSec device. Multiple tunnels may be defined between the 
same tunnel termination points, but each tunnel has a unique SPI and a unique key for encryption, 
decryption and authentication. Multiple keys may be associated with a secure tunnel. A tunnel 
provides for a one-way communication path between a sender and receiver. 
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An IPSec tunnel termination device such as the first network device 1 0 must have the correct 
addresses for the source and the destination, the correct SPI value and the correct key(s) for 
encryption and decryption to properly create a packet or datagram or message for sending and for 
deciphering (for receiving) a packet. The present invention recognizes that the information for the 
tunnel is unique for each direction of the tunnel, as shown in Fig. 4, and as indicated in Fig. 1 1 
depicting a logical portion of the tunnel definition database. The present invention also recognizes 
that a tunnel definition database (1 5, 25) which is stored in each IPSec device contains the necessary 
information, at the conclusion of the Internet Key Exchange (IKE) process, to enable a secure ping 
message to be sent firom a first IPSec device to a second IPSec device on a first IPSec tunnel and 
retumed fi*om the second IPSec device to the first IPSec device on a second IPSec tuimel The IKE 
process is used to establish the tunnels and tuimel definition database, as established in the 
documents setting up such communication protocols, such as those estabUshed by the IETF. 
Request for Comments (RFC) 2401, "Security Architecture for the Internet Protocol" and Request 
for Comments (RFC) 2409, "The Internet Key Exchange (IKE)," both pubhshed in November 1 998, 
are hereby incorporated by reference. Fig. 1 1 depicts a logical view of selected fields for the tunnel 
definition database. As those of ordinary skill in the art will recognize, the tunnel definition data 
bases (15, 25) contain many other fields in addition to those shown in Fig. 11, which may be used 
with the present invention. 

Still referring to Fig. 4, once the IKE process has occurred and the communication 
information has been obtained, communications using the tunnels can be estabUshed. In order to 
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conduct a communication over the secure tunnels 32,34 between the first network device 1 0 and the 
second network device 20, the first network device 10 possesses the address of the destination 
(second) network device 20, the address of the first network device 10, the SPI_1 and the Key_l 
necessary for use of the first tunnel 32 and the information (destination address, source address, 
SPI_2 and Key_2) necessary for use of the second tunnel 34 for a packet returning fi-om the second 
device 20 to the first device 10. The communication information is stored in a database associated 
with each IPSec device, that is, a database 15 associated with the first device 10 (device A) and a 
database 25 associated with the second device 20 (device B). 

Fig. 5 illustrates the principle of the present invention directed to how to get a "ping" packet 
to "tum around" at the destination device 20, once it has been sent fi:om the first device 1 0 using the 
first tunnel 32. A packet 40 is sent firom the first device 1 0 to the second device 20 through the first 
IPSec timnel 32. The packet 40 includes an outer header 42, an inner header 44 and the rest of the 
frame or message 46. The outer header 42 includes protocol information including the SPI_1 and 
the Key_l as well as the IP address of the tunnel source device 10 (shown here for exemplary 
purposes as 1.1.1.1) and the EP address of the tunnel destination device 20 (shown here for 
exemplary purposes as 2.2.2.1). The inner header 44 includes protocol information for the return 
message, that is, the header for use when the original destination system sends the "ping" message 
back to the original source system. The inner header 44 includes the protocol information for the 
return message (from the second device 20 as source to the first device 10 as destination, using the 
IP address of the second terminal, 2.2.2. 1 , as the source address and the IP address of the first device 
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10, 1.1.1.1 as the destination address) along with the SPI_2 and the Key_2 for the second tunnel 
Notice that the source and the destination addresses are inverted or reversed between the outer header 
42 and the inner header 44 so that the packet will turn around at the second device 20 for the return 
trip to the first device 10 via second secure tunnel 34. The rest of the frame or message 46 is 
included in the packet 40. 

When the packet 40 is received at the second device 20, the outer header 42a is discarded and 
the remainder of the packet 40 (the inner header 44A and the rest of the frame 46 A) is treated as 
usual at the second device 20 by putting it on an IP protocol stack, which is then handled by an IP 
routing function 26. The IP routing function 26 sees the remainder of the packet 40 (the inner header 
44a and the rest of the frame 46 A) as an outgoing message, addressed to the first device 10 from the 
second device through the second secure tunnel 34 back to the first device 10. 

Fig, 6 illustrates the packet 40 being sent from the first device 10 to the second device 20 (as 
shown in Fig. 5) through the first IPSec tunnel 32. As shown in Fig. 6, the packet or message 40 
includes the outer header 42 and the inner header 44 and the rest of the frame 46, with the inner 
header 44 and the rest of the frame 46 making up a return message portion 48. The return message 
portion 48 is pre-encapsulated with the SPI_2 and the Key_2 (not SPI_1 and Key_l ), with the SPI_2 
and Key_2 being the specific instances of the Security Parameter Index and encryption key that the 
second terminal 20 would use for return communications (rather than the SPI__1 and encryption 
Key_l) which the first device uses in its normal outgoing communications. When the second device 
20 receives the packet 40, it decapsulates the packet 40 and removes the outer header 42, much like 
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when a person removes the envelope in which postal service mail is mailed. The second device 20 
will not decapsulate the inner header 44 since the inner header address is not destined to the second 
device 20. The decapsulated packet will then be delivered to the IP protocol stack and the IP routing 
function 26 which will send the return message portion 48 of the message back to the first device 
5 10 and accompUsh the round trip of the IPSec Tunnel Ping (ITP). 

Fig. 7 illustrates the return message 48, as received by the first device 10 from the second 
terminal 20 through the second secure device 34. When the return message 48 is received by the 
p first device 10, it is desirable that the message be recognized as a returned "ping" message and 
01 discarded. This recognition depends on two attributes of the IPSec message: that it contains a nested 
IP header within the IPSec packet and that it includes one or more values in the nested IP header that 
J] can be made unique. The constructed return message 48 includes a header 48 A (the inner header 44 
O from the original packet 40 as described in connection with Figs.4-6) and an inner protocol data unit 
y (PDU) 49 with a third encapsulated IP header, including a source address 49A, a destination address 
p., 49B and a payload 49C. In the preferred embodiment of the invention, the source address 49A is 
15 set to an illegal value such as x'FFFFFFFF' and the protocol type is set to 50. While the payload 
49C is not defined by the current system, it may include a sequence number and a time stamp, so that 
the system can determine which ping is being retumed and when it was originally sent so that the 
time period for the ping can be determined. 

Fig. 8 illustrates the processing logic for handling a retumed IPSec message 48 at the first 
20 network device 10. The inbound fi*ame 48 flows into an IPSec function box 60 which includes an 
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IPSec decapsulation (decryption and removal of header 48 A) at logic block 62. Next, at decision 
block 64, the SPI (jfrom the header 48A) is tested to see if it is a defined protocol (such as 50 or 51. 
If the result is "yes" at decision block 64, then at decision block 66, a test is made to determine if the 
destination address is the same as the address of the first network device. If yes, the process 
continues at decision block 68 where the source address 49A in the third encapsulated IP header is 
tested for the "illegal value" of xTFFFFFFF'. If the source address 49A for the inbound fi-ame is 
not the illegal value, then processing control returns to logic block 62 to handle the next inbound 
frame. If the source address 49A for the inbound frame is the illegal value of x'FFFFFFFF', then 
the "receive ITP function" is executed in logic block 69, indicating that an EPSec ping has been 
successfully received back from the second device, and that the second device and the intervening 
network, including the secure IPSec tunnels 32, 34 are functioning properly. 

If the result of the test in decision block 64 is "no", indicating that the protocol type is not 
proper (50 or 5 1 for EPSec), then control proceeds to decision block 70 where the destination address 
is tested to see if the message is addressed to the first device 10 with its Internet Protocol (IP) 
address. If the answer is yes in decision block 70, then the inbound frame is put on the local queue 
function at logic block 72, that is, the message is something other than an IPSec message or a IPSec 
ping message. If either decision block 66 or decision block 70 yields a no answer, indicating that 
an inbound firame is not addressed to the first device 10 with its IP address, then the inbound frame 
is handled by a forwarding function at logic block 74 to send it to the proper network device. 
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Fig. 9 illustrates the entire message 40 as originally formulated by the first device 1 0 to begin 
the process of the ping of a secure tunnel as described in connection with the present invention. The 
entire message 40 includes the retum message 48 which, in turn, includes the innermost PDU 49 
which includes the third IP header 49 A, 49B and the payload 49C, as discussed above. The returned 
portion 48 is encrypted with the Key_2 and the SPI_2 (which would normally be used by the second 
device 20), and then the so-encrypted returned message 48 plus the header 42A are encrypted with 
the Key_l and the SPI_1 of the first device, with all the encryption taking place at the first device 
10. 

Fig. 1 0 illustrates the use of the present invention in the context of an Intemet system 80 with 
a first network 82 communicating with a second network 84 through the Intemet. Associated with 
the first network 82 is a firewall 82A and a firewall 84A is associated with the second network 84. 
Each of the firewalls 82A, 84A would have associated key(s) and SPI value(s) through some key 
distribution system such as the Intemet Key Exchange (IKE), not shown, but various methods of key 
distribution are well known to those involved in the art. The firewalls 82A, 84A define the secure 
tunnels into each network, allowing traffic (inbound messages) only from devices which are known 
to it and authorized by it to communicate with the respective associated networks. For the first 
network 82 to test the tunnels and communications between it and the second network 84, it must 
test the secure tunnels going both ways. That is, a message firom the first network device 82 to the 
second network device must test the firewall 84A and the retum message from the second network 
device 84 to the first network device 82 must test the firewall 82 A on the retum. 
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The present invention can be realized in hardware, software, or a combination of hardware 
and software. Any kind of computer system or other apparatus adapted for carrying out the methods 
described herein is suited. A typical combination of hardware and software could be a general 
purpose computer system with a computer program that, when being loaded and executed, controls 
the computer system such that it carries out the methods described herein. The present invention can 
also be embedded in a computer program product, which comprises all the features enabling the 
implementation of the methods described herein, and which, when loaded in a computer system, is 
able to carry out these methods. 

Computer program means or computer program in the present context mean any expression, 
in any language, code or notation, of a set of instructions intended to cause a system having an 
information processing capability to perform a particular fimction either directly or after either or 
both of the following occur: a) conversion to another language, code or notation; b) reproduction 
in a different material form. 

Those skilled in the art will appreciate that many modifications to the preferred embodiment 
of the present invention are possible without departing from the spirit and scope of the present 
invention. For example, the present invention can be extended to systems with multiple back-up 
tunnels. Furthermore, the use of physical security pipes instead of logical security pipes could be 
used to advantage. Alternatively, a mode can be used where some of the communications spectrum 
is reserved for such secure pipes. Also, the "ping" of the present invention could be used where 
details of the security of the remote network device are known, since the "ping" works without 
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regard to the type of hardware and software which are located at the remote end (the destination). 
In addition, it is possible to use some of the features of the present invention without the 
corresponding use of other features. In this regard, it is possible to use a return path which is not 
secure to test the one-way communications of the network, and, in that case, it may not be necessary 
to provide a doubly-encapsulated message with all the additional information necessary to provide 
for round-trip securing of Internet protocol security. Further, it may be desirable to provide for 
testing the two secure paths separately rather than together, separately using some features of the 
preferred embodiment. Accordingly, the foregoing description of the preferred embodiment is 
provided for the purpose of illustrating the principles of the present invention and not in limitation 
thereof, since the scope of the present invention is defined solely by the appended claims. 



RAL9-1999-0036 USl 



-25- 



What is claimed is: 



1 . A system for verifying the availability of a back-up secure tunnel between a pair of network 
elements in a communications network, comprising: 

a first network element for originating and transmitting a back-up tunnel verification 
test message to a second network element using the back-up secure tunnel in 
response to the receipt of a back-up tunnel verification test conmiand; 

a second network element for receiving the backup tunnel verification test message 
and transmitting a response back to the first network element using the back- 
up secure tunnel; and 

a backup tunnel verification function logic module in the first network element for 
accumulating a number of failures to respond by the second network element 
to the backup tunnel verification tests performed during an active verification 
period and determining if the accumulated number of failures is less than a 
threshold value specified in the backup tunnel verification test conrmand. 

2. The system for verifying the availability of a back-up seciu-e tunnel of claim 1 wherein the 
backup timnel verification function logic module further determines the number of 
successful responses to the back up tunnel verification tests performed. 
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3. The system for verifying the availabiUty of a back-up secure tunnel of claim 1 further 
comprising a computer connected to the communications network and running a network 
management application that transmits the backup tunnel verification test command to the 
first network element. 

4. The system for verifying the availability of a back-up secure tunnel of claim 1 further 
comprising a console interface on the first network element for generating the backup tunnel 
verification test command. 

5. The system for verifying the availability of a back-up secure tunnel of claim 1 wherein the 
back-up tunnel verification fimction is initiated by a configuration of a network element that 
forms an endpoint of the back-up secure tunnel. 

6. The system for verifying the availability of a back-up secure tunnel of claim 1 further 
comprising two unidirectional tunnels that form the back-up secure tunnel. 

7. The system for verifying the availability of a back-up secure tunnel of claim 1 wherein the 
communications network is a virtual private network (VPN). 
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8. 



The system for verifying the availabiUty of a back-up secure tunnel of claim 1 wherein the 
back-up secure tunnel is an Internet Protocol Security (IPSec) tunnel 



9. The system for verifying the availability of a back-up secure tunnel of claim 8 wherein the 
back-up tunnel verification test message is an IPSec tunnel ping. 

10. The system for verifying the availability of a back-up secure tunnel of claim 1 further 
comprising a primary secure tunnel for handling data traffic between the pair of network 
elements. 

1 1 . The system for verifying the availability of a back-up secure tunnel of claim 1 wherein the 
backup tunnel verification test command includes an identification of the secure tunnel to 
test, and a time interval during which a number of backup tunnel verification tests are 
performed. 

12. The system for verifying the availability of a back-up secure tunnel of claim 1 1 wherein the 
backup tunnel verification test command further comprises a time to wait between each 
backup tunnel verification test and a payload size of a backup tunnel verification test packet. 
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1 3 . The system for verifying the availability of a back-up secure tunnel of claim 6 wherein a first 
back-up unidirectional tunnel is used to send aa Intemet Protocol Security (EPSec) tunnel 
ping from the first network element to the second network element, and a second back-up 
unidirectional tunnel is used to send a response IPSec tuimel ping from the second network 
element to the first network element. 

14. The system for verifying the availabiUty of a back-up secure turmel of claim 1 further 
comprising a plurahty of back-up secure tunnels between the pair of network elements. 

15. A method for verifying the availability of a back-up secure tunnel between a pair of network 
elements in a communications network, comprising the acts of: 

originating and transmitting a backup tunnel verification test message from a first 
network element to a second network element using the back-up secure 
tunnel in response to the receipt of a backup tunnel verification test 
command; 

receiving the backup tunnel verification test message from a second network element 
and transmitting a response back to the first network element using the back- 
up secure tunnel; and 

accumulating a nimiber of failures to respond by the second network element to the 
backup tunnel verification tests performed during an active verification 
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period and determining if the accumulated number of failures is less than a 
threshold value specified in the backup tunnel verification test command, 

16. The method for verifying the availability of a back-up secure tunnel of claim 15 further 
comprising determining the number of successful responses to the backup tunnel verification 
test. 

17. The method for verifying the availability of a back-up secure tunnel of claim 15 further 
comprising transmitting the backup tunnel verification test command from a network 
management application to the first network element. 

18. The method for verifying the availabihty of a back-up secure tunnel of claim 15 further 
comprising generating the backup tunnel verification test command at a console interface on 
the first network element. 

19. The method for verifying the availability of a back-up secure tunnel of claim 15 further 
comprising initiating a back-up tunnel verification function by an initial configuration of a 
network element that forms an endpoint of the back-up secure tunnel. 
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20. The method for verifying the availabihty of a back-up secure tunnel of claim 1 5 wherein the 
back-up secure tunnel is formed from two unidirectional tunnels. 

2 1 . The method for verifying the availability of a back-up secure tunnel of claim 1 5 wherein the 
communications network is a virtual private network (VPN). 

22. The method for verifying the availability of a back-up secure tunnel of claim 1 5 wherein the 
back-up secure tunnel is an Internet Protocol Security (IPSec) tunnel. 

23 . The method for verifying the availability of a back-up secure tunnel of claim 22 wherein the 
backup tunnel verification test message is an IPSec tunnel ping. 

24. The method for verifying the availability of a back-up secure tunnel of claim 1 5 wherein the 
backup tunnel verification test command includes an identification of the back-up secure 
tunnel to test, and a time interval during which a number of backup tunnel verification tests 
are performed. 

25. The method for verifying the availability of a back-up secure tunnel of claim 24 wherein the 
backup tunnel verification test command further comprises a time to wait between each 
backup tunnel verification test and a payload size of a backup tunnel verification test packet. 
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26. The method for verifying the availabihty of a back-up secure tumel of claim 20 wherein a 
first unidirectional tunnel is used to send an Internet Protocol Security (IPSec) tunnel ping 
from the first network element to the second network element, and a second unidirectional 
tunnel is used to send a response IPSec tunnel ping from the second network element to 
the first network element. 



27, A computer readable medium containing a computer program product for verifying the 
availability of a back-up secure tunnel between a pair of network elements in a 
communications network, the computer program product comprising: 

program instructions that originate and transmit a backup tunnel verification test 
message to a paired network element using the back-up secure tunnel in 
response to the receipt of a backup tunnel verification test command; 
program instructions that receive a backup tunnel verification test message and 
transmit a response back to a paired network element using the back-up 
secure tunnel; and 

program instructions that accumulate a number of failures to respond by the second 
network element to the backup tunnel verification tests performed during an 
active verification period and determine if the accumulated number of 
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failures is less than a threshold value specified in the backup tunnel 
verification test command. 

28. The computer program product for verifying the availability of a back-up secure tunnel of 
claim 27 fiirther comprising program instructions that determine the number of successfiil 
responses to the backup tunnel verification tests performed. 

29. The computer program product for verifying the availability of a back-up secure tunnel of 
claim 27 further comprising program instructions that receive the backup tunnel verification 
test command from a network management application. 

30. The computer program product for verifying the availabiUty of a back-up secure tunnel of 
claim 27 further comprising program instructions that generate the backup tunnel verification 
test command. 

3 1 . The computer program product for verifying the availability of a back-up secure tunnel of 
claim 27 wherein two unidirectional tunnels form the back-up secure tunnel. 

32. The computer program product for verifying the availability of a back-up secure tunnel of 
claim 27 wherein the back-up secure tunnel is an Internet Protocol Security (IPSec) tunnel. 
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33. 



The computer program product for verifying the availabihty of a back-up secure tumiel of 
claim 27 wherein the communications network is a virtual private network (VPN). 



34. The computer program product for verifying the availability of a back-up secure tunnel of 
claim 32 wherein the back-up tunnel verification test message is an IPSec tunnel ping. 

35. The computer program product for verifying the availability of a back-up secure tunnel of 
claim 27 wherein the backup tunnel verification test command includes an identification of 
the secure tunnel to test, and a time interval during which a number of back-up tunnel 
verification tests are performed. 

36. The computer program product for verifying the availability of a back-up secure tunnel of 
claim 35 wherein the backup tunnel verification test command further comprises a time to 
wait between each back-up tunnel verification test and a payload size of a back-up tunnel 
verification test packet. 

37. The computer program product for verifying the availability of a back-up secure tunnel of 
claim 31 wherein a first imidirectional tunnel is used to send an Internet Protocol Security 
(IPSec) tunnel ping from the first network element to the second network element, and a 
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second unidirectional tunnel is used to send a response IPSec tunnel ping from the second 
network element to the first network element. 



38. A method for determining the identity of a back-up secure tunnel between a pair of network 
elements in a communications network, comprising the acts of: 

obtaining a back-up tunnel policy name using a pointer to a back-up tunnel policy 

from a primary tunnel policy stored at a first network element; 
determining if the back-up secure tunnel is an Intemet Key Exchange (IKE) tunnel; 
if the back-up secure tunnel is an IKE tunnel, determining if an IKE phase II 

connection between the pair of network elements has been established; 
requesting an IKE phase I connection to generate an IKE phase II connection if it has 

not been estabhshed previously; 
generating the back-up tunnel identification when the IKE phase II connection has 

been established. 

39. The method for determining the identify of a back-up secure tunnel of claim 3 8 wherein the 
back-up secure tunnel is formed from two unidirectional tunnels. 

40. The method for determining the identify of a back-up secure tunnel of claim 38 wherein the 
communications network is a virtual private network (VPN). 
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41 . The method for determining the identify of a back-up secure tunnel of claim 38 wherein the 
back-up secure tunnel is an Internet Protocol Security (EPSec) tunnel. 



42 . A method for determining the identity of a back-up secure tunnel between a pair of network 
elements in a communications network, comprising the acts of: 

obtaining a back-up tunnel policy name using a pointer to a back-up tunnel pohcy 
from a primary tunnel pohcy stored at a first network element; 

determining if the back-up secure tunnel is a manually generated tunnel; 

generating the back-up tunnel identification if the back-up secure tunnel is a 
manually generated tunnel. 

43. The method for determining the identify of a back-up secure tunnel of claim 42 wherein the 
back-up secure tunnel is formed from two unidirectional tunnels. 



44. The method for determining the identify of a back-up secure tunnel of claim 42 wherein the 
communications network is a virtual private network (VPN). 



45 . The method for determining the identify of a back-up secure tunnel of claim 42 wherein the 
back-up secure tunnel is an Intemet Protocol Security (IPSec) tunnel. 
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SYSTEM AND METHOD TO VERIFY 
AVAILABILITY OF A BACK-UP SECURE TUNNEL 
ABSTRACT OF THE INVENTION 



A method and system for verifying the availability of a back-up virtual private network IP 
security (IPSec) tunnel between two network elements by originating a plurality of connection tests 
between the network elements. The first network element transmits a backup tunnel verification test 
message to the second network element over the back-up secure tunnel upon receipt of a backup 
tunnel verification test command. The back-up secure tunnel includes two unidirectional tunnels. 
The second network element receives the back-up tunnel verification test message over the first 
back-up unidirectional secure tunnel and transmits a response back to the first network element over 
the second back-up unidkectional secure tunnel. The number of failures to respond by the second 
network element to the backup tunnel verification tests performed during an active verification 
period specified in the backup tunnel verification test command are reported back to the source that 
initiated the back-up secure tunnel verification test. 
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the claims. 
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I hereby claim foreign priority benefits under Title 35, United States Code, §1 19 of any foreign application(s) 
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